A storage is computer-readable media capable of storing data in blocks. Storages face a myriad of threats to the data they store and to their smooth and continuous operation. In order to mitigate these threats, a backup of the data in a storage may be created at a particular point in time to enable the restoration of the data at some future time. Such a restoration may become desirable, for example, if the storage experiences corruption of its stored data, if the storage becomes unavailable, or if a user wishes to create a second identical storage.
A storage is typically logically divided into a finite number of fixed-length blocks. A storage also typically includes a file system which tracks the locations of the blocks that are allocated to each file that is stored in the storage. The file system also tracks the blocks that are not allocated to any file. The file system generally tracks allocated and free blocks using specialized data structures, referred to as file system metadata. File system metadata is also stored in designated blocks in the storage.
Various techniques exist for backing up a source storage. One common technique involves backing up individual files stored in the source storage on a per-file basis. This technique is often referred to as file backup. File backup uses the file system of the source storage as a starting point and performs a backup by writing the files to a destination storage. Using this approach, individual files are backed up if they have been modified since the previous backup. File backup may be useful for finding and restoring a few lost or corrupted files. However, file backup may also include significant overhead in the form of bandwidth and logical overhead because file backup requires the tracking and storing of information about where each file exists within the file system of the source storage and the destination storage.
Another common technique for backing up a source storage ignores the locations of individual files stored in the source storage and instead simply backs up all allocated blocks stored in the source storage. This technique is often referred to as image backup because the backup generally contains or represents an image, or copy, of the entire allocated contents of the source storage. Using this approach, individual allocated blocks are backed up if they have been modified since the previous backup. Because image backup backs up all allocated blocks of the source storage, image backup backs up both the blocks that make up the files stored in the source storage as well as the blocks that make up the file system metadata. Also, because image backup backs up all allocated blocks rather than individual files, this approach does not necessarily need to be aware of the file system metadata or the files stored in the source storage, beyond utilizing minimal knowledge of the file system metadata in order to only back up allocated blocks since free blocks are not generally backed up.
Image backup can be relatively fast compared to file backup because reliance on the file system is minimized. An image backup can also be relatively fast compared to a file backup because seeking during image backup may be reduced. In particular, during image backup, blocks are generally read sequentially with relatively limited seeking. In contrast, during file backup, blocks that make up individual files may be scattered in the source storage, resulting in relatively extensive seeking.
Although image backup may be fast compared to file backup, creation of a base backup of source storage can take hours and possibly days to complete, depending on the size of the source storage. Further, repeatedly backing up an entire source storage may be unnecessary where most of the allocated blocks in the source storage do not frequently change.
One alternative to creating multiple base backups is to employ a decremental backup system, also known as reverse incremental backup system. Decremental backup systems initially create a base backup to capture the state of a source storage at an initial point in time, then update the base backup to capture the state of the source storage at a subsequent point in time by modifying only those blocks in the base backup that were modified between the initial and subsequent points in time. Prior to the updating of the base backup, however, any original blocks in the base backup that correspond to the modified blocks are copied to a decremental backup, thus enabling restoration of the source storage at the initial point in time (by restoring the updated base backup and then restoring the decremental backup) or at the subsequent point in time (by simply restoring the updated base backup).
One common problem that is encountered when repeatedly backing up a source storage using a decremental backup system is the proliferation of decremental backups. For example, backups may be taken of a source storage on a weekly basis, resulting in the creation of 52 decremental backups of the source storage each year. While it may initially be beneficial to be able to restore the source storage to its state in a particular week, after several months or years it may be acceptable to only be able to restore the source storage to its state in a particular quarter, in order to reduce the number of backups to 1/12 of the previous number of backups. However, since each decremental backup depends on another decremental backup or on a base backup, it is not possible to simply delete 11 of every 12 weekly decremental backups in order to reduce a set of weekly backups to a set of quarterly backups.
Another problem encountered when repeatedly backing up a source storage using a decremental backup system is the potential for the inclusion of free blocks in successive backups. Continuing with the above example, a very large digital movie file may be copied onto the source storage, and then backed up by the decremental backup system during one of the weekly backups at the end of a quarter. However, once the shift from needing weekly backups to needing quarterly backups occurs, it may only be necessary to restore to the first week of the quarter, rendering the allocated blocks that correspond to the movie file that are stored in one or more of the weekly backups at the end of the quarter superfluous and needlessly retained.
The proliferation of decremental backups and retaining superfluous blocks in backups may increase the overall size requirements of a destination storage where the backups are stored, increase the bandwidth overhead of transporting the backups, increase the processing time associated with consolidating the backups, and/or increase the processing time associated with restoring the backups.
The subject matter claimed herein is not limited to embodiments that solve any disadvantages or that operate only in environments such as those described above. Rather, this background is only provided to illustrate one example technology area where some embodiments described herein may be practiced.